REMARKS 

This application has been reviewed in light of the Office Action dated 
December 27, 2006. Claims 4-1 2 are presented for examination, of which Claims 4, 8, 
and 12 are in independent form. Claims 4, 8, and 12 have been amended to define 
Applicants' invention more clearly. Favorable reconsideration is requested. 

Claims 4-7 are rejected under 35 U.S.C. § 101 as allegedly directed to non- 
statutory subject matter. At pages 2-3, the Office Action states, "this claimed subject 
matter lack a practical application of a judicial exception (law of nature, abstract idea, 
naturally occurring article/phenomenon) since it fails to produce a useful, and tangible 
result." Additionally, at pages 2-3, the Office Action states that the "claims are not 
directed towards the [sic] final result that is 'useful, tangible and concrete.'" This rejection 
is respectfully traversed for the following reasons. 

Applicants submit that Claim 4 does cover a practical application of a 
judicial exception. As noted in the M.P.E.P., 

A claimed invention is directed to a practical application of a 35 
U.S.C. §101 judicial exception when it: 

(A) "transforms" an article or physical object to a different state or 
thing; or 

(B) otherwise produces a useful, concrete and tangible result, 
based on the factors discussed below. 

(M.P.E.P. § 2106(IV)(C)(2))(emphasis added.) According to M.P.E.P. § 

2106(IV)(C)(2)(1) the inquiry into whether a claim covers a practical application of a 35 

U.S.C. 101 judicial exception begins with a threshold determination. 

M.P.E.P. § 2106(rV)(C)(2)(l) states: 

USPTO personnel first shall review the claim and determine if it 
provides a transformation or reduction of an article to a different state 
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or thing. If USPTO personnel find such a transformation or 
reduction, USPTO personnel shall end the inquiry and find that the 
claim meets the statutory requirement of 35 U.S.C. 101 . If USPTO 
personnel do not find such a transformation or reduction, they must 
determine whether the claimed invention produces a useful, concrete, 
and tangible result. 

Applicants submit that the method of Claim 4 transforms and reduces an 
article to a different state or thing. Claim 4 recites a method for a software application of a 
first format to access external data of a format different from the first format. The method 
includes receiving a transaction infrastructure object requesting data and a data service 
transaction name. The method also includes the steps of retrieving a data service 
transaction corresponding to the data service transaction name and converting the 
transaction infrastructure object into a different format using an input element of the data 
service transaction. In addition, the method includes sending the converted transaction 
infrastructure object to a data source, obtaining the data from the data source, transforming 
the data into a transaction infrastructure response object using an output element of the data 
service transaction, and retrieving the transaction infrastructure response object to be 
accessed by a Web page or a Web service. 

Applicants submit that the steps of "converting the transaction 
infrastructure object into a different format using an input element of the data service 
transaction" and "transforming the data into a transaction infrastructure response object 
using an output element of the data service transaction," provide transformation or 
reduction of an article to a different state or thing. In both cases there is a physical 
transformation of an article to a different thing. In the step of "converting the transaction 
infrastructure object into a different format using an input element of the data service 
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transaction," an article (transaction infrastructure object) is transformed (converted) to a 
different thing (a different format). In the step of "transforming the data into a transaction 
infrastructure response object using an output element of the data service transaction," an 
article (data) is transformed (converted) to a different thing (a transaction infrastructure 
response object). Thus, because the method of Claim 4 transforms an article to a different 
thing, Applicants believe that Claim 4 is directed to statutory subject matter under 35 
U.S.C. § 101. 

Furthermore, to meet the requirements of 35 U.S.C. § 101, "[t]he claimed 

invention as a whole must accomplish a practical application. That is, it must produce a 

'useful, concrete and tangible result.'" M.P.E.P. § 2106(II)(A) (quoting State Street Bank 

& Trust v. Signature Financial Group, Inc., 149 F.3d 1368, 1373, 47 USPQ2d 1596, 1601 

(Fed. Cir. 1998)). State Street provides the following example of a claimed invention that 

produces a useful, concrete, and tangible result: 

[Transformation of data, representing discrete dollar amounts, by a 
machine through a series of mathematical calculations into a final share 
price, constitutes a practical application of a mathematical algorithm, 
formula, or calculation, because it produces 'a useful, concrete and tangible 
result' -- a final share price momentarily fixed for recording and reporting 
purposes and even accepted and relied upon by regulatory authorities and in 
subsequent trades. 

State Street, 149 F.3d at 1373, 47 USPQ2d at 1601. 

It is respectfully submitted that if "transformation of data. . .into a final 

share price" is statutory subject matter, as in the State Street case, then the claimed steps of 

"converting the transaction infrastructure object into a different format using an input 

element of the data service transaction," and "transforming the data into a transaction 

infrastructure response object using an output element of the data service transaction," and 
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"retrieving the transaction infrastructure response object to be accessed by a Web pages or 
a Web service" also are statutory, because these steps constitute a practical application of a 
conversion and transformation to produce a "useful, concrete and tangible result", i.e., the 
requested data, transformed into a transaction infrastructure response object. 

Accordingly, Claim 4 is respectfully submitted to be directed to patentable 
subject mater under 35 U.S.C. § 101. Independent Claims 8 and 12 include subject matter 
similar to that of Claim 4, and therefore are submitted to be directed to patentable subject 
matter for the same reasons. Claims 5-7 depend from Claim 4 and also are believed to 
conform with the requirements of 35 U.S.C. § 101. Therefore, withdrawal of the rejections 
is respectfully requested. 

In Section 5 of the Office Action, Claims 1, 8, and 12 were rejected for 
failing to provide sufficient antecedent basis for a limitation in the claims. (Applicants 
understand the rejection of Claim 1 to be a rejection of Claim 4 because Claim 1 was 
canceled by Applicants' October 16, 2006 Amendment.) Specifically, these claims were 
rejected for lacking sufficient antecedent basis for "requested data" and "the data." 
Applicants have carefully reviewed and amended Claims 4, 8, and 12 to overcome the 
rejections, and therefore respectfully request withdrawal of the rejections in paragraph 5 of 
the Office Action. 

Claims 4, 8, and 12 were rejected under 35 U.S.C. § 1 12, second paragraph, 
as being indefinite, because the meaning of the term "an input element of the data service" 
allegedly is unclear. Applicants submit that Claims 4, 8, and 12 are sufficiently definite 
because the specification clearly defines an input element of the data service transaction. 
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Applicants, therefore traverse these rejections. In particular, the specification recites, in 
part: 

[0027] An exemplary definition of each element in this 
schema is set forth below. The transaction includes the root 
element of the XML transformation file and it may contain 
three child elements including input, output and data 
provider. . . 

[0028] The input describes the input desired to access the 
transaction. The content of this schema element describes, if 
transformation is to be done, how to convert the XML passed 
to data services to the format expected by the data provider. 
The input may consist of none to many elements, and may 
include length and XMLTag attributes. The output describes 
the output returned from the transaction. The content of this 
schema element describes, if transformation is to be done, 
how to convert from the format returned by the data provider 
to the XML passed from data services. The output can consist 
of none to many elements, and may include the XMLTag 
attribute. 

Applicants submit that a person of ordinary skill in the art would be able to understand the 
meaning of the phrase "an input element of the data service transaction" in light of 
paragraphs 27 and 28 of the specification of the present application. 

Similarly, Claims 4, 8, and 12 were rejected under 35 U.S.C. § 1 12, second 
paragraph, as being indefinite because the meaning of the term "an output element of the 
data service" transaction allegedly is unclear. Applicants submit that Claims 4, 8, and 12 
are definite because the specification clearly defines an output element of the data service 
transaction in paragraphs 27 and 28. Applicants submit that a person of ordinary skill in 
the art would be able to understand the meaning of the phrase "an output element of the 
data service transaction" in light of paragraphs 28 and 29 of the specification of the present 
application. Applicants therefore respectfully request withdrawal of the claim rejections of 
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Claims 4, 8, and 12 under 35 U.S.C. § 112, second paragraph, as presented in Section 6 of 
the Office Action. 

Claims 5-7 and 9-1 1 depend from one or the other of Claims 4 and 8 and 
therefore are believed to be definite under 35 U.S.C. § 1 12, second paragraph for the same 
reasons discussed above with regard to Claims 4, 8, and 12. 

The Office Action states that Claims 4-12 are rejected under 35 U.S.C. § 
103(a) as being unpatentable over U.S. Patent No. 6,604,100 (Fernandez), in view of U.S. 
Patent No. 6,772,413 (Kuznetsov). Applicants submit that independent Claims 4, 8, and 
12, together with the claims dependent therefrom, are patentably distinct from the cited 
prior art for at least the following reasons. 

The aspect of the present invention set forth in Claim 4 is directed to a 
method for a software application of a first format to access external data of a format 
different from the first format. The method includes receiving a transaction infrastructure 
object requesting data and a data service transaction name. The method also includes the 
steps of retrieving a data service transaction corresponding to the data service transaction 
name and converting the transaction infrastructure object into a different format using an 
input element of the data service transaction. In addition, the method includes sending the 
converted transaction infrastructure object to a data source, obtaining the data from the data 
source, transforming the data into a transaction infrastructure response object using an 
output element of the data service transaction, and retrieving the transaction infrastructure 
response object to be accessed by a Web page or a Web service. 

Two notable features of Claim 4 are "converting the transaction 
infrastructure object into a different format using an input element of the data service 
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transaction" and "transforming the data into a transaction infrastructure response object 
using an output element of the data service transaction." These steps distinguish between a 
transaction infrastructure object, a transaction infrastructure response object, and data. The 
distinction between data objects and data is key to understanding the difference between 
the teachings of Kuznetzov and Claim 4. 

Kuznetzov relates to data conversion between two different formats such 
that data is converted from one format to another format, while remaining as data. 
Apparently, Kuznetzov teaches that the data format of data can be translated according to 
information known about the data formats of the source and destination of the data, by 
creating specific data translator programs for an identified pair of source and destination. 
Thus, as Applicants understand Fernandez, if entity A requires data in format A from a 
source B that has data in format B, a program will be written specifically to do the data 
conversion of the data from format B into format A and entity A will have data available in 
the native format of A. This is not what is claimed in Claim 4. 

Nothing has been found in Kuznetzov that is believed to teach or suggest 
"converting the transaction infrastructure object into a different format using an input 
element of the data service transaction" and "transforming the data into a transaction 
infrastructure response object using an output element of the data service transaction." 

As stated in the specification of the present application: 

[0005] . . .The access to the external data is provided via an 
interface that takes a request object and returns a response 
object. The objects include "application syntax," and make 
the underlying protocol/data formats invisible to the user of a 
system of the present invention. 
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[0007] To retrieve data from a new data source, it is only 
necessary to create a new DST. In such a manner, a requestor 
can retrieve data without the need to translate data into a 
particular format. . . 

(Specification, paragraphs 5 and 7.) 

One of ordinary skill in the art would understand the difference between an 

object and data as those terms are used in Claim 4 and the specification of the present 

application. In addition, the specification also states: 

An "object" used herein includes small program that performs 
a specific function (e.g., send a query to a database or send 
results of a query to another object or application). As such, 
programs can utilize the "services" of objects without having 
to contain the code internally, thus saving development time, 
code redundancy and a theoretical increase in computing 
efficiency... 

(Specification, paragraph 21.) The Office Action appears to confuse an object with data by 
pointing to FIG. 6 of Kuznetzov. Section 7 of the Office Action cites to item 707 of FIG 6. 
in Kuznetzov as being the same as the "data" of Claim 4. However, the Office Action also 
states that item 705 of FIG. 6 of Kuznetzov is the data of Claim 4 that is to be transformed 
into the transaction infrastructure response object. Applicants submit that items 707 and 
705 cannot both be the data of Claim 4 "data" and still conform to the teaching of 
Kuznetzov' s specification. 

In Kuznetzov, the "Translator Compiler Engine" is apparently a program 
that generates a data translator. Therefore the "Translator Compiler Engine" is apparently 
not the data to be translated, but a program to further generate a program to translate the 
data. In addition item 705 of FIG. 6 is described as an output data stream, which is not the 
same as an object, since it is well known in the art that a data object is itself a program. A 
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data object is not simply reformatted data, but is itself a program. This is not taught or 
suggested by Kuznetzov. 

Additionally, in section 7 of the Office Action, there is no discussion of how 
item 701 of FIG. 6 of Kuznetzov functions as both a transaction infrastructure object and a 
transaction infrastructure response object. In light of the specification and drawings of 
Kuznetzov, one of ordinary skill in the art would not appreciate that the input data stream 
of FIG. 6 would be the same as a "transaction infrastructure object" and a "transaction 
infrastructure response object," as those terms are used in Claim 4 and understood by one 
of ordinary skill in the art and in light of the specification of the present application. The 
result of the data translation of Kuznetzov is to output a data stream in a different format. 
Because this data stream is not an object, Kuznetzov does not disclose, teach, or suggest the 

features of Claim 4. 

The transformation of data into a transaction infrastructure response object 
also results in benefits that are possible by using objects, rather than simply data format 
conversion. Because objects are known to be programs that perform a specific function, 
programs can utilize the "services" of objects without having to contain the program code 
internally. This saves development time, code redundancy, and theoretically increases 
computing efficiency. Specifically, if the objects take the form of Microsoft .NET objects, 
portability can be added to applications by allowing a program to be written in multiple 
languages and compiled as one. (Specification, paragraph 21.) Kuznetzov does not 
disclose, teach, or suggest the desirability of converting objects or transforming data into 
objects to produce such benefits. 
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Fernandez relates to converting relational data into XML (extensible 
Markup Language). Apparently, the Fernandez approach involves taking an RXL query 
and decomposing it into one or more SQL queries and an XML template. The SQL queries 
are executed by a server or engine, and their flat results (streams or tuples) are converted 
into XML by the XML generator. Col. 9, Ins. 60-65. The XML query language, XML-QL, 
apparently can be implemented in Java as well. Col. 25, Ins. 55-60. Again, Fernandez 
does not teach or suggest an "object requesting data" or a "response object." Apparently 
Fernandez teaches only how to generate XML, which is not an object, as one of ordinary 
skill in the art would recognize. 

Finally, the Office Action cites column 11, lines 65-68, column 12, lines 1- 
5, column 5, lines 65-68, and column 6, lines 1-5 for the proposition that Kuznetsov 
discloses the requisite motivation to modify Fernandez by using the data service 
transaction code, because using such a data transaction code has been well known in the 
art. Applicants have reviewed the cited portions of Kuznetzov and find no teaching or 
suggestion of using a data service transaction, nor using data objects. Therefore, 
Applicants submit that there is no motivation to combine the teachings of Fernandez and 
Kuznetzov in the manner recited in the Office Action. 

Therefore, Applicants submit that a combination of Fernandez and 
Kuznetsov, assuming such combination would even be permissible, would fail to teach or 
suggest the steps quoted above from Claim 4. 

Accordingly, Applicants submit that Claim 4 is patentable over the cited art, 
and respectfully request withdrawal of the rejection under 35 U.S.C. § 103(a). Independent 
Claims 8 and 12 are computer program product and system claims respectively 
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corresponding to method Claim 4, and are believed to be patentable for at least the same 
reasons as discussed above in connection with Claim 4. Therefore, those claims also are 
believed to be patentable for at least the same reasons as discussed above. 

The other rejected claims in this application depend from one or another of 
the independent claims discussed above and, therefore, are submitted to be patentable for at 
least the same reasons. Because each dependent claim also is deemed to define an 
additional aspect of the invention, individual consideration or reconsideration, as the case 
may be, of the patentability of each claim on its own merits is respectfully requested. 

This Amendment After Final Action is believed clearly to place the present 
application in condition for allowance. Therefore, entry of this Amendment under 37 
C.F.R. § 1 . 1 16 is believed proper and is respectfully requested, as an earnest effort to 
advance prosecution and reduce the number of issues. Should the Examiner believe that 
issues remain outstanding, it is respectfully requested that the Examiner contact 
Applicants' undersigned attorney in an effort to resolve such issues and advance the case to 
issue. 

In view of the foregoing amendments and remarks, Applicants respectfully 
request favorable reconsideration and early passage to issue of the present application. 

No petition to extend the time for response to the Office Action is deemed 
necessary for this Amendment. If, however, such a petition is required to make this 
Amendment timely filed, then this paper should be considered such a petition and the 
Commissioner is authorized to charge the requisite petition fee to Deposit Account 06- 
1205. 
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Applicants' undersigned attorney may be reached in our New York Office 



by telephone at (212) 218-2100. All correspondence should continue to be directed to our 



address listed below. 



Respectfully submitted, 




L<fek See 
Attorney for . 
Registration No. 38,667 
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FITZPATRICK, CELLA, HARPER & SCINTO 
30 Rockefeller Plaza 
New York, New York 10112-3801 
Facsimile: (212)218-2200 



NY Main 611285 1 
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